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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the protocols to be used when ITU-T Q.1902 "Bearer Independent Call Control" is 
used as call control protocol in a 3GPP Bearer Independent CS core network 3GPP TS 23.205 [1] The Q.1902 operates 
between (G)MSC servers .The BICC architecture as described in ITU-T Q.1902 [6]-[10] consists of a number of 
protocols. The following types of protocols are described: call control protocol, bearer control protocols and a resource 
control protocol for this architecture. The architecture complies with the requirements imposed by 3GPP TS 23.205 [1] 
and TS 23.153 [2]. 

The present document is valid for a 3"" generation PLMN (UMTS) complying with Release 4 and later. 

Note: Q.1902 can be used in other network architectures than the one defined in 3GPP TS 23.205 [1] 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of pubhcation, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[ 1 ] 3GPP TS 23 .205 : "Bearer Independent CS Core Network - Stage 2" . 

[2] 3GPP TS 23153: "Out of Band Transcoder Control - Stage 2". 

[3] 3GPP TS 29.232: "Media Gateway Controller (MGC) - Media Gateway (MGW) Interface; Stage 

3". 

[4] 3GPP TS 29.414: "Core Network Nb Data Transport and Signalling Transport". 

[5] ITU-T Recommendation Q.765.5 (06/2000): "Application Transport Mechanism". 

[6] ITU-T Recommendation Q. 1902. 1 (07/2001): "Bearer Independent Call Control CS2 Functional 

Description". Inclusive Amendment 3: "Support for the Customized Alerting Tone (CAT) 
service". 

[7] ITU-T Recommendation Q. 1902.2 (07/2001): "Bearer Independent Call Control CS2 General 

functions of messages and parameters". Inclusive Amendment 5: "Support for the Customized 
Alerting Tone (CAT) service". 

[8] ITU-T Q. 1902.3 (07/2001): "Bearer Independent Call Control CS2 Formats and Codes". Inclusive 

Amendment 5: "Support for the Customized Alerting Tone (CAT) service". 

[9] ITU-T Recommendation Q. 1902.4 (07/2001): "Bearer Independent Call Control CS2 Basic Call 

Procedures". 

[10] ITU-T Recommendation Q. 1902.5 (07/2001): "Exceptions to the Application Transport 

Mechanism in the Context of Bearer Independent Call Control". 

[11] ITU-T Recommendation Q. 1902. 6 (07/2001): "Generic Signalling Procedures for the support of 

the ISDN User Part Supplementary Services and for bearer redirection". 

[12] ITU-T Recommendation Q. 1950 (07/2001): "Call Bearer Control Protocol". 

[13] ITU-T Recommendations Q.2630.1 (12/1999), Q.2630.2 (12/2000): "AAL type 2 signalling 

protocol". 
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[14] ITU-T Recommendation Q. 1990 (07/2001): "BICC Bearer Control tunnelling protocol". 

[15] ITU-T Recommendation Q. 1970 (07/2001): "BICC IP Bearer Control protocol". 

[16] ITU-T Recommendation Q. 1912. 1 (07/2001): "Interworking between Signalling System No. 7 

ISDN user part and the Bearer Independent Call Control protocol". 

[17] ITU-T Recommendation Q. 1912.2 (07/2001): "Interworking between selected Signalling System 

(PSTN Access DSSl, C5, Rl, R2, TUP) and the Bearer Independent Call Control Protocol". 

[18] ITU-T Recommendation Q.2150.0 (05/2001): "Generic Signalling Transport Service". 

[19] ITU-T Recommendation Q.2150. 1 (05/2001): "Signalling Transport Converter on MTP3 and 

MTP3b". 

[20] ITU-T Recommendation Q.2150.3 (12/2002): "Signalling Transport Converter on SCTP". 

[21] ITU-T Recommendation H.248.4 (1 1/2000): "Gateway Control Protocol: Transport over SCTP". 

[22] 3GPP TS 29.202: "SS7 signalling transport in core network". 

[23] ITU-T Recommendation H.248.5 (1 1/2000): "Gateway control protocol: Transport over ATM". 

[24] ITU-T Q.765 (06/2000): "Signalling system No. 7 - Application transport mechanism". 

[25] 3GPP TS 23.003: "Numbering, addressing and identification". 

[26] 3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2". 

[27] 3GPP TS 23.237: "IP Multimedia subsystem (IMS) Service Continuity; Stage 2". 

[28] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[29] 3GPP TS 23.284: "Local Call Local Switch; Stage 2". 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

Nc Interface between the (G)MSC servers. 

Mc Interface between the server and the media gateway. 

Nb Interface between media gateways (MGW). 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations as defined in 3GPP TR 21.905 [28] and the following 
apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if 
any, in3GPP TR 21.905 [28]. 

APM Application Transport Mechanism 

Application Transport Message 

APP Application Transport Parameter 

BAT Bearer Association Transport 

BICC Bearer Independent Call Control 

C5 CCITT signalling system number 5 

GCR Global Call Reference 
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LCLS 

M3UA 

MGC 

MST 

Rl 

R2 

SCTP 

SN 

TUP 



Local Call Local Switch 
MTP3 - User Adaptation Layer 
Media Gateway Controller 
Mobile Service Transport 
Regional Signalling System 1 
Regional Signalling System 2 
Stream Control Transmission Protocol 
Serving Node 
Telephony User Part 



4 Protocols 

Implementations providing any of the interfaces or protocols identified in the subclauses below shall implement the 
requirements of the specifications identified in those subclauses. 

4.1 Call control protocol (Nc interface) 



Q.1 902.1 


BlCC PRQTQCOL (CS2) FUNCTIONAL DESCRIPTION [6] 


Q.1902.2 


BICC PROTOCOL (CS2) AND SIGNALLING SUSTEM NO 7 ISUP 
GENERAL FUNCTIONS OF MESSAGES AND PARAMETERS [7] 


Q.1902.3 


BICC PROTOCOL (CS2) AND SIGNALLING SYSTEM NO 7 ISUP 
FORMATS AND CODES [8] (NOTE) 


Q.1 902.4 


BICC (CS2) BASIC CALL PROCEDURES [9] 


Q.1902.5 


EXCEPTIONS TO THE APM IN THE CONTEXT OF BICC [1 0] 
AMENDMENT TO ITU-T RECOMMENDATION 0.765.5 FOR BICC CS2 [5] 


Q.1902.6 


GENERIC SIGNALLING PROCEDURES AND SUPPORT OF THE ISDN USER PART SUPPLEMENTARY 
SERVICES WITH THE BEARER INDEPENDENT CALL CONTROL PRQTQCOL [11] 


NOTE: The "Backward CAT indicators" parameter sliall be encoded as an optional 3-octet parameter in the ACM, 

CPG and SEG messages rather than as a 1 -octet parameter as incorrectly defined in Amendment 5 of ITU-T 
Recommendation Q.1902.3 [8]. 



4.2 Interworking with other protocols 



Q.1912.1 



ISUP-BICC INTERWORKING [16] 



Q.1912.2 



INTERWORKING BETWEEN SELECTED SIGNALLING SYSTEMS (PSTN ACCESS DSS1 C5 R1 R2 TUP) 
AND THE BEARER INDEPENDENT CALL CONTROL PRQTQCOL [1 7] 



4.3 Resource control protocol (G)I\/ISC and IVIGW (IVIc 
Interface) 

3GPP TS 29.232 | "Media Gateway Controller (MGC) - Media Gateway (MGW) lnterface;Stage 3" [3] 
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4.4 Bearer control protocol between MGWs (Nb interface) 



3GPP TS 
29.414 



"Core Network Nb Data Transport and Signalling Transport" [4] 

including ITU-T Recommendation Q.1970 "IP bearer control protocol" [15] , ITU-T Recommendation 

Q.I 990 "BICC tunneling control protocol" [14] , ITU-T Recommendation Q.2630.1-2 "AAL type 2 signalling 

protocol" [13]. 



4.5 Signalling Transport 
4.5.1 Call Control protocols 



Q.2150.0 


"Generic Signalling Transport Service" [18] 


Q.2150.1 


"Signalling Transport Converter on MTP3 and MTP3b" [19] 


Q.2150.3 


"Signalling Transport Converter on SCTP" [20] 


3GPP TS 29.202 


"SS7 signalling transport in core network" [22] Annex A: The use of M3UA in 3GPP networks. 



4.5.2 Resource control protocol (G)MSC and IVIGW (IVIc Interface) 



3GPP TS 
29.232 



"Media Gateway Controller (IVIGC) - Media Gateway (MGW) Interface; Stage 3" [3] 
including ITU-T Recommendation H.248.4 "Transport over SCTP" [21], ITU-T Recommendation H.248.5 
"Transport over ATM" [23], and 3GPP TS 29.202 "SS7 signalling transport in core network" [22] Annex A: 
The use of M3UA in 3GPP networks. 



4.5.3 Bearer control protocol between IVIGWs (Nb interface) 



3GPP TS 
29.414 



"Core Network Nb Data Transport and signalling transport" [4] 

including ITU-T Recommendation Q.2630.1-2: "AAL type 2 signalling protocol" [13] and the tunnel-up 

and tunnel-down procedure in 3GPP TS 29.232 [31] 
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Annex A: Void 
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Annex B (normative): 

Transparent Support of Mobile Services 

B.1 Introduction 

This Annex specifies a new mobile APM usage "Transparent support of mobile services". 

In ITU-T Recommendation Q. 1902.3 [8], for the Application Transport Parameter (AFP), the following codepoint is 
defined to refer to this application context identifier (ACI): 



00001 1 1 



MST <as defined in ETSI TS 129.205> 



The text in ITU-T Recommendation Q. 1902.5 [10] shall be followed when implementing this application with the 
following clarification: 

where the text refers to BAT ASE this shall be interpreted to mean Mobile Service Transport (MST) service. 

The MST service shall use implicit addressing; see ITU-T Recommendation Q.765 [24]. 

B.2 Mobile Service Transport (MST) - Format and Codes 

B.2.1 Encapsulated Application Information 
B. 2.1.1 General Layout 

The general layout of the Encapsulated Application Information field of the Application Transport parameter as defined 
in ITU-T Recommendation Q. 1902.3 [8] is shown in Table B.2. 1.1.1. 

Table B.2. 1.1.1: Encapsulated application information field 



MSB 
8 


7 


6 5 4 3 


2 


LSB 

1 


Octet 


Identifier 1 


1 


Length indicator 1 


2 


Compatibility information 1 


3 


Contents 1 


4 






Identifier n 


m 


Length indicator n 




Compatibility information n 




Contents n 


P 



Each information element within the Encapsulated Application Information field has the same structure. An information 
element consists of four fields which always appear in the following order: Identifier (one octet), Length indicator, 
Compatibility information. Contents. 



£75/ 



3GPP TS 29.205 version 10.3.0 Release 10 



12 



ETSI TS 129 205 VI 0.3.0 (2012-01) 



The Identifier distinguishes one type from another one and governs the interpretation of the contents. There are two 
types of Identifiers: type "constructor" and type "simple", for which the contents are defined as follows: 

For a "constructor" type, the Contents field shall again consist of one or more information elements, each of 
which is structured as described above, i.e.. Identifier, Length indicator. Compatibility information. Contents. 

For a "simple" type, the Contents field contains one value only. 

When passing on an information element of type "constructor", the order of the information elements within this 
"constructor" shall be maintained. 

The Length indicator specifies the length (i.e., integral number of octets in pure binary representation) of the 
Compatibility information and Contents. The length does not include the Identifier nor the Length indicator. 

The format of the Length indicator is shown in Table B. 2. 1.1.2. Bit 8 is defined as Extension indicator and indicates 
whether or not the information on the length continues through the next octet. Value "0" of the Extension indicator 
means "information continues through the next octet", while value "7" means "last octet" . The Length indicator itself 
has a maximum length of 2 octets, i.e., if octet la is needed, the Extension indicator of octet la is always set to value 

II 711 



Table B.2.1.1.2: Length indicator 



8 


7 


6 


5 


4 


3 


2 


1 


ext. 














LSB 


ext. 1 











MSB 









Octet 
1 
1a 



The Compatibility information contains corresponding instructions for the case that the received information element is 
unrecognised. The format of this field is shown in Table B. 2. 1.1. 3. 



ext. 



Table B.2.1.1.3: Compatibility information 



pass-on not possible 
send 



notification 
indicator 



instruction 
indicator 



reserved 



Octet 



general action 

send 
notificaton 



indicator 



instruction indicator 



The following codes are used in the subfields of the Compatibility information field. 

Bits 2 1 Instruction indicator for general action 

Pass on information element 

1 Discard information element 

1 Discard MST data 
1 1 Release call 

Bit 3 Send notification indicator for general action 

Do not send notification 

1 Send notification 
Bit 4 reserved 

Bits 6 5 Instruction indicator for pass-on not possible 

Release call 
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1 Discard information element 

1 Discard MST data 

1 1 reserved (interpreted as 00) 

Bit 7 Send notification indicator for pass-on not possible 

Do not send notification 

1 Send notification 
Bit 8 Extension indicator 

Information continues through the next octet 

1 Last octet 

The Contents field is the substance of the element and contains the information the element is intended to convey. 

B.2.1.2 List of Identifiers 

Table B. 2. 1.2.1 contains the list of Identifiers. 

Table B.2.1 .2.1 : List of identifiers 



Value 


Information element name 


Type 


Reference 


0000 0000 


spare 


- 




0000 0001 


Mobile Equipment Identifier 


simple 


B.2.1.3 


0000 0010 


LCLS Negotiation Request 


simple 


B.2.1. 4 


0000 0011 


LCLS Negotiation Response 


simple 


B.2.1.5 


0000 0100 


LCLS Status 


simple 


B.2.1.6 


0000 0101 


LCLS Status Cliange 


simple 


B.2.1.7 


0000 0110 


LCLS Status Result 


simple 


B.2.1.8 


0000 0111 


LCLS Global Call Reference 


simple 


B.2.1.9 


0000 1000 


LCLS Configuration Preference 


simple 


B.2.1. 10 


0000 1001 


LCLS Configuration Change 
Request 


simple 


B.2.1. 11 


0000 1010 


LCLS Configuration Change 
Result 


simple 


B.2.1. 12 


0000 1011 

to 
1101 1111 


reserved for 3GPP use 


- 




1110 0000 
to 

1111 1111 


reserved for national use 


- 





B.2.1.3 Mobile Equipment Identifier 

The format of the Mobile Equipment Identifier is shown in Table B.2.1. 3.1. 
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MSB 
8 



Table B.2. 1.3.1: Mobile Equipment Identifier 

LSB 



Mobile Equipment Identifier 



1 Octet 



The MEI contains either the International Mobile station Equipment Identity (IMEI) or the International Mobile station 
Equipment Identity and Software Version Number (IMEISV) as defined in subclause 6.2 of 3GPP TS 23.003 [25]. 

Both IMEI and IMEISV are TBCD encoded where IMEI is 15 digits and IMEISV is 16 digits. Bits 5 to 8 of octet n+1 
(where n represents the octet of the IMEI(SV) being encoded) encodes digit 2n, bits 1 to 4 of octet n+1 encodes digit 
2n-l (i.e. the order of digits is swapped in each octet compared to the digit order defined in 3GPP TS 23.003 [25]). For 
IMEI, bits 5 to 8 of the last octet shall be filled with an end mark coded as '1111'. 

For the use of the Mobile Equipment Identifier (MEI) see 3GPP TS 23.216 [26] and 3GPP TS 23.237 [27]. 

B.2.1 .4 LCLS Negotiation Request 

The format of the LCLS Negotiation Request is shown in Table B.2.1. 4.1. 

Table B.2.1 .4.1: LCLS Negotiation Request 



Octet 

1 



MSB 














LSB 


8 


7 


6 


5 


4 


3 


2 


1 


Extension Indicator 


Spare 


Permission Indicator 



The LCLS Negotiation Request is sent in the forward direction to indicate LCLS usage permission. 



Bit 12 

00 
01 
10-11 



Permission Indicator 

LCLS is allowed 
LCLS is not allowed 
Reserved for future use 



Bit 3 - 7 



Spare 



Bits 


1 



Extension Indicator 

information continues in next octet 
last octet 



For the use of the LCLS Negotiation Request IE see Annex C.2.1 and 3GPP TS 23.284 [29]. 

B.2.1 .5 LCLS Negotiation Response 

The format of the LCLS Negotiation Response is shown in Table B.2.1. 5.1. 
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Table B.2.1.5.1: LCLS Negotiation Response 

MSB LSB 



8 


7 


6 


5 


4 


3 


2 


1 


Spare 


Permission 
Indicator 



Octet 
1 



The LCLS Negotiation Response contains information sent in the backwards direction to indicate resuh of the LCLS 
Negotiation Request. The LCLS Negotiation Response is coded as follows: 

Bits 1 2 Permission Indicator 

00 LCLS is allowed 

01 LCLS is not allowed 

10 LCLS is not supported by a subsequent node 

1 1 spare 

Bits 3 - 8 Spare 

For the use of the LCLS Negotiation Response IE see Annex C.2.2and 3GPP TS 23.284 [29]. 

B.2.1.6 LCLS Status 

The format of the LCLS Status is shown in Table B. 2. 1.6.1. 

Table B.2.1 .6.1 : LCLS Status 

• IVISB . LSB 

' Octet 

1 



8 


7 


6 


5 


4 


3 


2 


1 


LCLS Status 



The LCLS Status contains information sent in forward and backward directions to indicate LCLS connection status. The 
LCLS Status is coded as follows: 

Value Meaning 

0000 0000 no indication 

0000 0001 LCLS is feasible but not yet connected 

0000 0010 LCLS not connected 

0000 00 1 1 LCLS connected 

All other values are reserved. 

For the use of the LCLS Status IE see Annex C.2.3, C.2.5 and 3GPP TS 23.284 [29]. 

B.2.1 .7 LCLS Status Change 

The format of the LCLS Status Change is shown in Table B.2.1. 7.1. 

Table B.2.1 .7.1 : LCLS Status Change 

IVISB LSB 



LCLS Status Change 



Octet 

1 



The LCLS Status Change Identifier contains information sent in forward and backward directions to indicate requested 
change of LCLS connection status. The LCLS Status Change Identifier is coded as follows: 



Value 



Meaning 
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0000 0000 LCLS connection preparation 

0000 0001 LCLS disconnection preparation 

0000 0010 LCLS disconnection preparation for Handover 

All other values are reserved. 

For the use of the LCLS Status Change IE see Annex C.2.6 and 3GPP TS 23.284 [29]. 

B.2.1.8 LCLS Status Result 

The format of the LCLS Status Result is shown in Table B. 2.1. 8.1. 

Table B.2.1.8.1 : LCLS Status Result 

MSB LSB 



8 7 6 


5 4 3 2 


1 


Spare 


Rejection Indicator 


Acceptance 
Indicator 



Octet 

1 



The LCLS Status Result contains information sent in forward and backward directions to indicate result of the LCLS 
Status Change Request. The LCLS Status Result is coded as follows: 

Acceptance Indicator 

LCLS Status Change request accepted 
LCLS Status Change request rejected 



Rejection Indicator 

No indication 

Ongoing supplementary service 

Reserved for future use 

Spare 



Bitl 



1 




Bits 2 3 4 5 

0000 
0001 
0010-1111 



Bits 6 - 8 



For the use of the LCLS Status Result IE see Annex C.2.6 and 3GPP TS 23.284 [29]. 

B.2.1 .9 LCLS Global Call Reference 

The format of the LCLS Global Call Reference (GCR) is shown in Table B.2.1. 9.1. 
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Table B.2.1.9.1: LCLS Global Call Reference 



MSB 



LSB 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Network ID length indicator 


1 


Network ID 
(variable length 3-5 octets) 


2 

4+m (m=0,1,2) 


Node ID length indicator 


5+m 


Node ID 
(fixed length: 2 octets) 


6+m 
7+m 


Call Reference ID length indicator 


8+m 


Call Reference ID 
(fixed length: 5 octets) 


9+m 

13+m 



The LCLS GCR is information sent in forward direction to uniquely identify a call and correlate activities associated 
with that call. The LCLS GCR is coded as follows: 

Network ID length indicator 

Binary coded information indicating the number of octets in the Network ID field. 

- Network ID 

Information identifying a network. The Network ID field is specified in ITU-T Recommendation Q. 1902.3 [8]. 

Node ID length Indicator 

Binary coded information indicating the number of octets in the Node ID field. 

- Node ID 

A binary number that uniquely identifies within the network the node which generates the call reference. 

Call Reference ID length indicator 

Binary coded information indicating the number of octets in the Call Reference ID field. 

Call Reference ID 

A binary number used for the call reference of the call. It is generated by the originating serving node for each 

call. 

NOTE: If the originating serving radio access is GERAN the format of the Call Reference ID subfield is shown in 
Table B.2.L9.2. The originating BSS ID is an integer that uniquely identifies the Base Station Subsystem 
(BSS) Node within an operator's network. 

Table B.2.1.9.2: Call Reference ID 



MSB 



LSB 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Call Identifier 
(fixed length: 3 octets) 


1 
2 
3 


Originating BSS ID 
(fixed length: 2 octets) 


4 
5 



For the use of the LCLS GCR IE see Annex C.2.1 and 3GPP TS 23.284 [29]. 
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B. 2.1. 10 LCLS Configuration Preference 

The format of the LCLS Configuration Preference is shown in Table B.2. 1.10.1. 

Table B.2. 1.10.1: LCLS Configuration Preference 



IVISB 














LSB 


8 


7 


6 


5 


4 


3 


2 


1 


Extension 
Indicator 


Spare 


Backward Data 
Reception Indicator 


Forward Data 
Reception 
Indicator 


Bacl<ward Data 
Sending Indicator 


Forward Data 
Sending Indicator 



Octet 
1 



The LCLS Configuration Preference contains information sent in forward and backward directions to indicate 
negotiated LCLS configuration preference. 



Bitl 


1 



Forward Data Sending Indicator 

not required 
required 



Bit 2 


1 



Backward Data Sending Indicator 

not required 
required 



Bit 3 


1 



Forward Data Reception Indicator 

not required 
required 



Bit 4 


1 



Backward Data Reception Indicator 

not required 
required 



Bits 5 - 7 Spare 

Bit 8 Extension Indicator 

information continues in next octet 

1 last octet 



For the use of the LCLS Configuration Preference IE see Annex C.2.1, C.2.2, C.2.4 and 3GPP TS 23.284 [29]. 

B.2.1 .1 1 LCLS Configuration Cinange Request 

The format of the LCLS Configuration Change Request is shown in Table B.2. 1 . 1 1 . 1 . 

Table B.2.1. 11.1: LCLS Configuration Change Request 

IVISB LSB 

' Octet 

1 



8 


7 


8 


5 


4 


3 


2 


1 


Extension Indicator 


Spare 


Type 



The LCLS Configuration Change Request contains information sent in the forward and backward directions to indicate 
type of LCLS Configuration Change Request. 



Bit 12 

00 
01 - 11 



Type 

LCLS Configuration Preference Modification Request 
Spare 
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Bit 3 - 7 



Spare 



Bits 


1 



Extension Indicator 

information continues in next octet 
last octet 



For the use of the LCLS Configuration Change Request IE see Annex C.2.4 and 3GPP TS 23.284 [29]. 

B. 2.1. 12 LCLS Configuration Cinange Result 

The format of the LCLS Configuration Change Result is shown in Table B.2.L12.L 

Table B.2. 1.12.1: LCLS Configuration Change Result 

MSB LSB 



8 7 6 


5 4 3 2 


1 


Spare 


Rejection Indicator 


Acceptance 
Indicator 



Octet 

1 



The LCLS Configuration Change Result contains information sent in the backward direction to indicate result of the 
LCLS Configuration Change Request. The LCLS Configuration Change Result is coded as follows: 

Bit 1 Acceptance Indicator 

LCLS Configuration Change request accepted 

1 LCLS Configuration Change request rejected (if set then Rejection Indicator provides further 
details) 

Bits 2 3 4 5 Rejection Indicator 

0000 No indication 

0001 Requested LCLS configuration not supported 

0010 Ongoing supplementary service 

00 11 - 1111 Reserved for future use 

Bits 6 - 8 Spare 

For the use of the LCLS Configuration Change Result IE see Annex C.2.4 and 3GPP TS 23.284 [29]. 

B.2.2 Application Transport Instruction Indicators 

For the MST service the Application Transport Instruction Indicators (ATII) shall be set as follows: 
Bits 1 Release call indicator (RCI) 

do not release call 

Bit 2 Send notification indicator (SNI) 

do not send notification 
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Annex C (normative): LCLS Service Application 

LCLS Service is defined in 3GPP TS 23.284 [29] and is dependent on the following identifiers being included in 
BICC/ISUP messaging. The following sections describe the detailed protocol behaviour when these identifiers are 
included. 



C.1 UseofMSTASE 



LCLS service makes use of the services of the MST ASE described in Annex B. The services of the MST ASE are 
accessed by means of primitives (such as "MST_data") which are the same as BAT ASE primitives defined in ITU-T 
Recommendation Q. 765. 5 [5]. 



C.2 Procedures 

C.2.1 Indication of LCLS Capability 
0.2.1 .1 LCLS Service Capability Indication 

LCLS service shall be used for a call if MST_data primitive associated with an lAM includes LCLS Information 
Elements: a LCLS GCR, a LCLS Negotiation Request and a LCLS Configuration Preference. The absence of the LCLS 
Negotiation, the LCLS Configuration Preference and the LCLS GCR Information Elements in the lAM specifies that 
the LCLS service shall not be used. 

The compatibility information of the LCLS Negotiation Request, the LCLS Configuration Preference and the LCLS 
GCR Information Elements shall be set so as to cause the Information Element to be discarded by nodes that do not 
support LCLS service. 

The procedures for call establishment using the LCLS service are described in 3GPP TS 23.284 [29]. 



C.2.1 .2 Actions at Originating Serving Node 



An originating Serving Node (SN) that supports the LCLS service shall indicate this within the lAM message of the 
mobile originating call by including the LCLS Negotiation Request, the LCLS Configuration Preference and the LCLS 
GCR Information Elements within the MST Application Transport Parameter (APP) within the lAM. 

When the LCLS service is allowed to be used the lAM is sent to the succeeding node with the Permission Indicator of 
the LCLS Negotiation Request Information Element set to "LCLS is allowed". 

Depending on network requirements the originating SN may additionally indicate required configurations for user plane 
connectivity towards originating or terminating UE within the LCLS Configuration Preference Information Element. If 
the originating MSC server needs to: 

send data towards the terminating UE it shall set Forward Data Sending Indicator to "required"; 

send data towards the originating UE it shall set Backward Data Sending Indicator to "required"; 

receive data from the originating UE it shall set Forward Data Reception Indicator to "required"; 

receive data from the terminating UE it shall set Backward Data Reception Indicator to "required". 

The originating SN shall perform the setting of LCLS Configuration Preference Information Element according to rules 
specified in sub-clause 4.2 of 3GPP TS 23.284 [29] or it may determine that LCLS is not allowed and indicate this by 
setting the value of Permission Indicator of the LCLS Negotiation Request Information Element to "LCLS is not 
allowed". 



£75/ 



3GPP TS 29.205 version 1 0.3.0 Release 1 21 ETSI TS 1 29 205 V1 0.3.0 (201 2-01 ) 

C.2.1 .3 Actions at Intermediate Serving Node 

For the intermediate Serving Node (SN), LCLS service indication (i.e. LCLS GCR, LCLS Negotiation Request and 
LCLS Configuration Preference Information Elements) shall be included only if received from the preceding node and 
if the node itself supports the LCLS service. 

The intermediate SN shall not change the LCLS GCR Information Element. If the intermediate SN receives Permission 
Indicator of the LCLS Negotiation Request Information Element set to "LCLS is not allowed" it shall not change it. 

Depending on network requirements the intermediate SN may additionally indicate required configurations for user 
plane connectivity towards originating or terminating UE by changing the received LCLS Configuration Preference 
Information Element. If the intermediate SN needs to: 

send data towards the terminating UE it shall set Forward Data Sending Indicator to "required"; 

send data towards the originating UE it shall set Backward Data Sending Indicator to "required"; 

receive data from the originating UE it shall set Forward Data Reception Indicator to "required"; 

receive data from the terminating UE it shall set Backward Data Reception Indicator to "required". 

If the intermediate SN receives any of these indicators set to "required" it shall not change them. 

C.2.1 .4 Actions at Destination Serving Node 

For the destination Serving Node (SN), LCLS service shall be supported only if the lAM with the LCLS Negotiation 
Request, LCLS Configuration Preference and LCLS GCR Information Elements within the MST Application Transport 
Parameter ( APP) is received from the preceding node and if the node itself supports the LCLS service. 

Depending on network requirements the destination SN may additionally modify received configurations for user plane 
connectivity towards originating or terminating UE, by changing the settings of the LCLS Configuration Preference 
Information Element. If the destination SN needs to: 

send data towards the terminating UE it shall set Forward Data Sending Indicator to "required"; 

send data towards the originating UE it shall set Backward Data Sending Indicator to "required"; 

receive data from the originating UE it shall set Forward Data Reception Indicator to "required"; 

receive data from the terminating UE it shall set Backward Data Reception Indicator to "required". 

If the destination SN receives any of these indicators set to "required" it shall not change them. 

The destination SN shall perform modification of LCLS Configuration Preference Information Element according to 
rules specified in sub-clause 4.2 of 3GPP TS 23.284 [29] or it may determine that LCLS is not allowed and shall 
indicate this by setting the value of Permission Indicator of the LCLS Negotiation Response Information Element to 
"LCLS is not allowed". 

C.2.2 Backward LCLS Negotiation during Call Setup 
C.2.2.1 Introduction 

LCLS service shall be used for a call if MST_data primitive associated with first backward (APM or ACM) message 
includes a LCLS Negotiation Response and a LCLS Configuration Preference Information Elements. The absence of 
the LCLS Negotiation Response and the LCLS Configuration Preference Information Elements in the first backward 
message specifies that the LCLS service shall not be used. 

The compatibility information of the LCLS Negotiation Response and the LCLS Configuration Preference Information 
Elements shall be set so as to cause the Information Element to be discarded by nodes that do not support LCLS service. 
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C.2.2.2 Actions at Destination Serving Node 

If LCLS service is supported according to conditions specified in sub-clause C.2.1.4 a destination SN shall include in 
the first backward message (APM or ACM) the LCLS Negotiation Response and the LCLS Configuration Preference 
Information Elements in the MST_Data request primitive. 

C.2.2.3 Actions at Intermediate Serving Node 

If LCLS service is supported according to conditions specified in sub-clause C.2.L3 but a succeeding node does not 
return LCLS Negotiation Response Information Element in the first backward message, an Intermediate SN shall 
include the LCLS Negotiation Response Information Element. The Permission Indicator of the LCLS Negotiation 
Response Information Element shall be set to "LCLS is not supported by a subsequent node". 

On receipt of a backward message (APM, ACM or CPG) with the LCLS Negotiation Response and the LCLS 
Configuration Preference Information Elements the Intermediate SN shall store the LCLS configuration settings from 
the LCLS Configuration Preference Information Element and shall forward the LCLS Negotiation Response and the 
LCLS Configuration Preference Information Elements unchanged. 

C.2.2.4 Actions at Originating Serving Node 

If the first backward message does not contain the LCLS Negotiation Response and the LCLS Configuration Preference 
Information Elements the originating SN shall assume that LCLS is not supported by succeeding node and LCLS shall 
not be performed for that call; no further LCLS signalling shall take place for that call. 

If the first backward message contains the LCLS Negotiation Response Information Element but the Permission 
Indicator is set to "LCLS Not Allowed" or "LCLS is not supported by a subsequent node" then the originating SN shall 
not request establishment of the LCLS connection at this time. 

NOTE: A subsequent LCLS Negotiation Response Information Element can be received from succeeding nodes, 
e.g. in the event of a call forwarding on no reply. 

C.2.3 Answer message 
C.2.3.1 Introduction 

LCLS connection may be established for a call if MST_data primitive associated with an ANM includes a LCLS Status 
Identifier Information Element. The absence of the LCLS Status Identifier Information Element in the ANM specifies 
that the LCLS connection shall not be requested. 

The compatibility information of the LCLS Status Identifier shall be set so as to cause the Information Element to be 
discarded by nodes that do not support LCLS service. 

C.2.3. 2 Actions at Destination Serving Node 

If a destination SN determines that LCLS service is feasible according to the conditions specified in sub-clause 6.2.L3.4 
of 3GPP TS 23.284 [29] it shall include the LCLS Status Identifier Information Element set to "LCLS feasible but not 
yet connected" within the MST Application Transport Parameter (APP) within the ANM. 

C.2.3. 3 Actions at Intermediate Serving Node 

An Intermediate SN shall pass the LCLS Status Identifier within the ANM unchanged. 

C.2.3. 4 Actions at Originating Serving Node 

When an originating SN receives an ANM with the LCLS Status Identifier indicating the LCLS service is feasible it 
shall request LCLS connection. 
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C.2.4 LCLS Configuration Change Request 
0.2.4.1 Introduction 

Modification of a LCLS configuration can only occur after the LCLS negotiation has been performed during the call 
set-up phase according to the procedures described in sub-clauses C.2.1 and C.2.2. A SN involved in a LCLS 
Configuration Change procedure must not initiate a new LCLS Configuration Change Request until the existing LCLS 
Configuration Change procedure has been completed. 

A LCLS Configuration Change Request message may be sent in either direction and at any time during the active phase 
of a call, after the LCLS negotiation has been performed during the call establishment. A LCLS Configuration Change 
Request and a LCLS Configuration Preference Information Elements indicating the requested change of the LCLS 
configuration shall be included in a MST_data primitive, corresponding to an APM message. 

A MST_Data primitive, corresponding to the APM message shall be issued in response, including the LCLS 
Configuration Preference and the LCLS Configuration Change Result Information Elements indicating if the requested 
change of LCLS configuration has been accepted and if it has not been accepted the reason for rejection. 

The compatibility information of the LCLS Configuration Preference, the LCLS Configuration Change Request and 
LCLS Configuration Change Result Information Elements shall be set so as to cause the Information Element to be 
discarded and send notification by nodes that do not support LCLS service. 

NOTE: The term "initiating" SN in the following clauses refers to a SN which initiates the LCLS Configuration 
Change Request. The term "terminating" SN in the following clauses refers to a SN which terminates the 
LCLS Configuration Change Request. 



0.2.4.2 Actions at Initiating Serving Node 



If a SN determines that LCLS configuration needs to be changed it may send an APM message which includes a LCLS 
Configuration Change Request and the LCLS Configuration Preference Information Elements to its succeeding and/or 
preceding node. The initiating SN shall set the desired configurations as described in sub-clause C.2.1. 2. 

The LCLS Configuration Change Request may only be initiated if LCLS Negotiation was performed during call 
establishment. 

NOTE: this does not require that LCLS was permitted during the call establishment. 

On receipt of an APM message containing the LCLS Configuration Preference and the LCLS Configuration Change 
Result Information Elements, if the result indicates "accepted" the modification of the LCLS Configuration settings has 
been successful. If the LCLS Configuration Change Result Information Element indicates "rejected" the initiating SN 
shall resume the LCLS connection with the LCLS configuration unchanged. 

0.2.4.3 Actions at Intermediate Serving Node 

When an intermediate SN receives an APM message with the LCLS Configuration Change Request and the LCLS 
Configuration Preference Information Elements requesting a certain LCLS Configuration Change the intermediate SN 
shall check if it can support the requested LCLS configuration. If the intermediate SN can support the proposed LCLS 
configuration it shall forward the LCLS Configuration Preference and the LCLS Configuration Change Request 
Information Elements to its succeeding or preceding node. If the intermediate SN cannot support/permit the proposed 
LCLS configuration it shall respond with a LCLS Configuration Change Result Information Element set to "LCLS 
Configuration Change request rejected" along with the Rejection Indicator detailing the reason for rejection. 

On receipt of an APM message with the LCLS Configuration Change Result and LCLS Configuration Preference 
Information Elements from its succeeding/preceding node if the LCLS Configuration Change Result Information 
Elements indicates "accepted" the intermediate SN shall store the LCLS configuration settings from the LCLS 
Configuration Preference Information Element and shall forward the APM message to its preceding/succeeding node. 

If the LCLS Configuration Change Result Information Element indicates "rejected" the intermediate SN shall resume 
the LCLS connection with the LCLS configuration unchanged and the intermediate SN shall forward the APM message 
to its preceding/succeeding node. 
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C.2.4.4 Actions at Terminating Serving Node 

When an SN which is a terminating SN with respect to a LCLS Configuration Change Request receives an APM 
message with the LCLS Configuration Change Request and LCLS Configuration Preference Information Elements 
requesting a certain LCLS Configuration Change the terminating SN shall check if it can support the requested LCLS 
configuration. 

If the terminating SN can support the proposed LCLS configuration change it shall return the LCLS Configuration 
Preference Information Element and the LCLS Configuration Change Result Information Element indicating 
acceptance of the LCLS Configuration Change to its succeeding or preceding node. If the terminating SN cannot 
support/permit the proposed LCLS configuration it shall respond with a LCLS Configuration Change Result 
Information Element set to "LCLS Configuration Change request rejected" along with the Rejection Indicator detailing 
the reason for rejection. 

C.2.5 LCLS Status Update 
C.2.5.1 Introduction 

A LCLS Status Update message may be sent in either direction to indicate that a LCLS connection status has been 
changed. A LCLS Status Identifier Information Element indicating the new LCLS connection status value shall be 
included in a MST_data primitive, corresponding to an APM message. 

The compatibility information of the LCLS Status Identifier shall be set so as to cause the Information Element to be 
discarded and send notification by nodes that do not support LCLS service. 

NOTE: The term "initiating" SN in the following clauses refers to an originating SN or a destination SN that may 
initiate the LCLS Status Update message. The term "terminating" SN in the following clauses refers to an 
originating SN or a destination SN that may receive the LCLS Status Update message. 

C.2.5. 2 Actions at Initiating Serving Node 

If a SN determines that the LCLS connection status has been changed it shall send the new LCLS connection status 
value to an adjacent SN. An initiating SN shall send the LCLS Status Identifier Information Element within the MST 
Application Transport Parameter (APP) within the APM message. 

C.2.5. 3 Actions at Intermediate Serving Node 

When an intermediate SN receives the APM message with the LCLS Status Identifier Information Element from the 
preceding/succeeding SN and if the same LCLS connection status value has not been already received from the 
succeeding/preceding SN, the intermediate SN shall store the new LCLS Connection status value and shall pass the 
LCLS Status Identifier Information Element within the APM message unchanged to its succeeding/preceding SN. 

C.2.5. 4 Actions at Terminating Serving Node 

When a terminating SN receives the APM message with the LCLS Status Identifier Information Element from the 
adjacent SN, it shall update its LCLS connection status value. 

C.2.6 LCLS Status Change Request 
C.2.6.1 Introduction 

A LCLS Status Change Request message may be sent in either direction and at any time during the active phase of a 
call, after the LCLS has been initially established. A LCLS Status Change Identifier Information Element indicating the 
requested change of the LCLS connection status shall be included in a MST_data primitive, corresponding to an APM 

message. 
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An MST_Data primitive, corresponding to the APM message shall be issued in response, including the LCLS Status 
Change Identifier Information Element and a LCLS Status Result Identifier Information Element indicating if the 
requested change of LCLS connection status has been accepted and if it has not been accepted the reason for rejection. 

The compatibility information of the LCLS Status Change Identifier and the LCLS Status Result Identifier shall be set 
so as to cause the Information Element to be discarded and send notification by nodes that do not support LCLS service. 

NOTE: The term "initiating" SN in the following clauses refers to a SN which initiates the LCLS Status Change. 
The term "terminating" SN in the following clauses refers to a SN which terminates the LCLS Status 
Change. 

C.2.6.2 Actions at Initiating Serving Node 

When a SN determines that the LCLS connection status needs to be changed, it shall request the change of the LCLS 
connection status from its preceding and/or succeeding SN. An initiating SN shall send the LCLS Status Change 
Identifier Information Element within the MST Application Transport Parameter (AFP) within an APM message. 

An APM message containing the LCLS Status Change Identifier Information Element and a LCLS Status Result 
Identifier Information Element will be received in response from the succeeding and/or preceding SN. 

If initiating SN is an SN serving a Radio Network (originating SN or destination SN), upon reception of the LCLS 
Status Result Identifier Information Element indicating the acceptance of the requested LCLS connection status change, 
the initiating SN shall change the LCLS connection status. 

NOTE: This change of LCLS connection status can be deferred until signalling interaction with the served Radio 
Network Controller, which is outside of the scope of this specification. 

C.2.6.3 Actions at Intermediate Serving Node 

When an intermediate SN receives from a preceding/succeeding SN an APM message that includes a LCLS Status 
Change Identifier Information Element within the MST Application Transport Parameter (APP) it shall check if it can 
support the required change of the LCLS connection status. 

If the intermediate SN cannot support the requested change of the LCLS connection status it shall respond to the 
preceding/succeeding SN with the APM message containing the LCLS Status Change Identifier Information Element 
and a LCLS Status Result Identifier Information Element with an Acceptance indicator set to "LCLS Status Change 
request rejected" along with a Rejection Indicator detailing the reason for rejection. 

If the intermediate SN can support the required change of the LCLS connection status it shall pass the LCLS Status 
Change Identifier Information Element within the APM message unchanged to its succeeding/preceding SN. An APM 
message will be received in response, including the LCLS Status Change Identifier Information Element and a LCLS 
Status Result Identifier Information Element from its succeeding/preceding SN. The intermediate SN shall pass the 
LCLS Status Change Identifier Information Element and the LCLS Status Result Identifier Information Element within 
the APM message unchanged to its succeeding/preceding SN. 

C.2.6.4 Actions at Terminating Serving Node 

Upon reception of an APM message that includes a LCLS Status Change Identifier Information Element, from the 
adjacent SN, a terminating SN shall check if it can support the required change of the LCLS connection status. 

If the terminating SN can support the required change, it shall change the LCLS connection status. If the result of the 
LCLS connection status change is successful the terminating SN shall send to the adjacent SN the APM message with 
the LCLS Status Change Identifier Information Element and a LCLS Status Result Identifier Information Element 
indicating the acceptance of the requested LCLS connection status change. 

NOTE: If the terminating SN is an SN serving a Radio Network (originating SN or destination SN), there can be 
additional signalling with the served Radio Network Controller, prior to responding to the LCLS Status 
Change Request; this is, however, outside of the scope of this specification. 

If the result of the LCLS connection status change is unsuccessful or if the terminating SN cannot support the required 
change it shall respond to the adjacent SN with the APM message containing the LCLS Status Change Identifier 
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Information Element and a LCLS Status Result Identifier Information Element with an Acceptance indicator set to 
"LCLS Status Change request rejected" along with a Rejection Indicator detailing the reason for rejection. 
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